feat: onboarding setup-ruby action - #1

PR Review

Action Type

Node-based — uses node24 runtime as declared in action.yml, with dist/index.js as the bundled entry point.

Passed Checks

• License: LICENSE file present with dual copyright — original author Benoit Daloze (2019) and StepSecurity (2026).
• action.yml: Present with author: 'step-security'.
• SECURITY.md: Present at repo root.
• No FUNDING.yml: Absent as required.
• Workflow files: Both .github/workflows/auto_cherry_pick.yml and .github/workflows/actions_release.yml are present.
• No renovate.json: Absent as required.
• No PULL_REQUEST.md: Absent as required.
• No ISSUE_TEMPLATE folder: Absent as required.
• No CHANGELOG.md: Absent as required.
• No .vscode folder: Not tracked in the repository (correctly listed in .gitignore).
• dist folder: dist/index.js is present and committed.
• README banner: StepSecurity maintained action banner is present on line 1 of README.md.
• README versioning: All usage examples reference step-security/setup-ruby@v1 (major version only, no full semver tags).
• Subscription check: index.js calls https://agent.api.stepsecurity.io/v1/github/${process.env.GITHUB_REPOSITORY}/actions/maintained-actions-subscription.
• Upstream variable: upstream = 'ruby/setup-ruby' correctly matches original-owner: "ruby" and repo-name: "setup-ruby" from auto_cherry_pick.yml.
• package.json author: "author": "step-security".
• package.json repository: URL contains step-security.
• No unused dependencies: All declared dependencies are actively used across the codebase.
• Build script input: Both actions_release.yml and audit_package.yml expose script as a workflow input (required since the package manager is yarn, not npm).

Failed Checks

• Workflow file naming: The requirement specifies a file named .github/workflows/audit_fix.yml, but the file in this repo is named audit_package.yml. It calls the reusable audit_fix.yml workflow and meets the functional requirement (script input is present), but the filename does not match the expected convention.

Warnings

• exportCommandEnv in windows.js (line 220): The function builds a cmd.exe /s /c string by embedding the command argument directly via template literal. Callers pass paths derived from tool-cache or vswhere output (not direct user input), but if any embedded path contains characters like ", &, |, or > the shell command could misbehave. This is a pre-existing upstream pattern; consider sanitizing path characters before embedding.
• process.chdir on user input (index.js:88): The working-directory input is passed directly to process.chdir() without sanitization, allowing path traversal (e.g., ../../). This is by-design for the action's functionality but is worth acknowledging.

Security Findings

Shell command injection risk — windows.js:220: exportCommandEnv constructs a raw cmd.exe command string by embedding the command parameter without escaping special characters. If the rubyPrefix or vcVars path (sourced from vswhere) contains shell meta-characters, the injected string could alter execution flow. Consider sanitizing or validating path characters before embedding in the shell string.

All other code paths examined show no significant security vulnerabilities.

Summary

The onboarding PR is well-structured and passes nearly all required checks. The only failing check is the naming of the audit workflow file (audit_package.yml vs. the expected audit_fix.yml). The shell command construction in windows.js:220 is a low-severity pre-existing upstream pattern that should be reviewed for hardening.